A smooth transition from build to run
In our previous blog posts, we talked about the continuous delivery flow. This consists of everything needed to bring software to production with a short lead time, iteratively and securely. Accountability remains with the same team during the transition. This is a consequence of the DevOps attitude: you build it, you run it. So building and keeping a piece of software up and running are not separated, only the rules of the game change.
In order to clarify this, let's take a look at NASA's way of working. They make a clear distinction between launch control and mission control. Launch control is responsible until the count reaches 0 and the rocket ignites. Until that point, they can abort at any time. This is similar to a continuous delivery pipeline that has built-in checks and can interrupt the process if minimum requirements are not met. Once the rocket has taken off, mission control takes over because from then on it is impossible to simply stop a flying rocket. Everything is monitored, and if something does happen they can still try to limit the damage. To a certain extent, this is comparable to putting software into production. Once the software is live and the users start working with it, it is not so easy to reverse the process. Fortunately, there are some release strategies where we have more control than NASA does in space.
Release strategies to keep things under control as much as possible
By separating deployment of a new version of certain aspects from the release of certain features, a whole world of possibilities opens up. Deployment is about the binaries (a set of executable files that perform a particular function), while release is about the functionality. In too many cases, these two things go together. The following strategies keep you much more in control:
- Blue-green deployment: A new version is placed next to the old one. A self-selected pilot group of users gets access to the new version so they can test it in production. If all goes well, the switch can be made so that everyone uses the new version.
- Canary release: This strategy gets its name from the little yellow birds that were formerly used to detect any signs of gas leaks in mines. Here again, there are two versions side by side. A random 10% of users get to see the new version via load balancing. This percentage is steadily increased. If something goes wrong, the percentage drops again.
- Feature flags: Certain new features are already available in the code, but not yet visible to users. This makes testing in production possible. It is even conceivable that a user is given the choice of using the old screen of a particular feature or the new one already. In that case they will be asked "Do you want to test the beta version now?" This also makes it easier to integrate auto-healing concepts. If the monitoring system detects a problem with the new feature since the activation of a certain feature flag, for example, it can be automatically turned off.